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CNJ ■ Abstract. KiCS2 is a new system to compile functional logic programs of the source lan- 

^q' guage Curry into purely functional Haskell programs. The implementation is based on the 

i—{ , idea to represent the search space as a data structure and logic variables as operations that 

generate their values. This has the advantage that one can apply various, and in particu- 
lar, complete search strategies to compute solutions. However, the generation of all values 
0^ ■ for logic variables might be inefficient for applications that exploit constraints on partially 

known values. To overcome this drawback, we propose new techniques to implement equa- 
tional constraints in this framework. In particular, we show how unification modulo function 
"l ■ evaluation and functional patterns can be added without sacrificing the efficiency of the ker- 

^ ' nel implementation. 

t/3 ! 

1 Introduction 

Functional logic languages combine the most important features of functional and logic program- 

• ming in a single language (sec [5, 17] for recent surveys). In particular, they provide higher-order 
functions and demand-driven evaluation from functional programming together with logic pro- 

• gramming features like non-deterministic search and computing with partial information (logic 
| variables). This combination has led to new design patterns [2,6] and better abstractions for 

00 ' application programming, but it also gave rise to new implementation challenges. 

Previous implementations of functional logic languages can be classified into three categories: 

7— I \ 

1. designing new abstract machines appropriately supporting these operational features and im- 
J> | plementing them in some (typically, imperative) language, like C [24] or Java [7, 20] , 

2. compilation into logic languages like Prolog and reusing the existing backtracking implementa- 
r> | tion for non-deterministic search as well as logic variables and unification for computing with 

■ partial information [1,23], or 

3. compilation into non-strict functional languages like Haskell and reusing the implementation 
of lazy evaluation and higher-order functions [13, 14]. 

The latter approach requires the implementation of non-deterministic computations in a deter- 
ministic language but has the advantage that the explicit handling of non-determinism allows for 
various search strategics like depth-first, breadth-first, parallel, or iterative deepening instead of 
committing to a fixed (incomplete) strategy like backtracking [13]. 

In this paper we consider KiCS2 [12], a new system that compiles functional logic programs 
of the source language Curry [21] into purely functional Haskell programs. We have shown in 
[12] that this implementation can compete with or outperform other existing implementations 
of Curry. KiCS2 is based on the idea to represent the search space, i.e., all non-deterministic 
results of a computation, as a data structure that can be traversed by operations implementing 
various strategics. Furthermore, logic variables are replaced by generators, i.e., operations that non- 
deterministically evaluate to all possible ground values of the type of the logic variable. It has been 
shown [4] that computing with logic variables by narrowing [27, 30] and computing with generators 
by rewriting arc equivalent, i.e., compute the same values. Although this implementation technique 
is correct [9], the generation of all values for logic variables might be inefficient for applications 
that exploit constraints on partial values. For instance, in Prolog the equality constraint "X=c(a)" 



is solved by instantiating the variable X to c(a), but the equality constraint "X=Y" is solved by 
binding X to Y without enumerating any values for X or Y. Therefore, we propose in this paper new 
techniques to implement equational constraints in the framework of KiCS2 (note that, in contrast 
to Prolog, unification is performed modulo function evaluation). Furthermore, we also show how 
functional patterns [3], i.e., patterns containing evaluable operations for more powerful pattern 
matching than in logic or functional languages, can be implemented in this framework. We show 
that both extensions lead to efficiency improvements without sacrificing the efficiency of the kernel 
implementation. 

In the next section, we review the source language Curry and the features considered in this 
paper. Section 3 sketches the implementation scheme of KiCS2. Sections 4 and 5 discuss the 
extensions to implement unification modulo functional evaluation and functional patterns, respec- 
tively. Benchmarks demonstrating the usefulness of this scheme are presented in Sect. 6 before we 
conclude in Sect. 7. 

2 Curry Programs 

The syntax of the functional logic language Curry [21] is close to Haskell [26], i.e., type variables 
and names of defined operations usually start with lowercase letters and the names of type and data 
constructors start with an uppercase letter. The application of / to e is denoted by juxtaposition 
("/ e"). In addition to Haskell, Curry allows free (logic) variables in conditions and right-hand 
sides of defining rules. Hence, an operation is defined by conditional rewrite rules of the form: 

/ t\ . . .t n I c = e where vs free (1) 

where the condition c is optional and vs is the list of variables occurring in c or e but not in the 
left-hand side f ti . . . t n . 

In contrast to functional programming and similarly to logic programming, operations can be 
defined by overlapping rules so that they might yield more than one result on the same input. 
Such operations are also called non- deterministic. For instance, Curry offers a choice operation 
that is predefined by the following rules: 
x ? _ = x 

- ? y = y 

Thus, we can define a non-deterministic operation aBool by 
aBool = True ? False 

so that the expression "aBool" has two values: True and False. 

If non-deterministic operations are used as arguments in other operations, a semantical ambi- 
guity might occur. Consider the operations 



not True 




False 


not False 




True 


xor True 


x 


= not x 


xor False 


X 


= X 


xorSelf x 




xor x x 



and the expression "xorSelf aBool" . If we interpret this program as a term rewriting system, we 
could have the reduction 



xorSelf aBool — > xor aBool aBool — > xor True aBool 

—> xor True False — )■ not False — > True 

leading to the unintended result True. Note that this result cannot be obtained if we use a strict 
strategy where arguments are evaluated prior to the function calls. In order to avoid dependen- 
cies on the evaluation strategies and exclude such unintended results, Gonzalez-Moreno et al. [16] 
proposed the rewriting logic CRWL as a logical (execution- and strategy-independent) foundation 



for declarative programming with non-strict and non-deterministic operations. This logic specifics 
the call-time choice semantics [22] , where values of the arguments of an operation are determined 
before the operation is evaluated. This can be enforced in a lazy strategy by sharing actual argu- 
ments. For instance, the expression above can be lazily evaluated provided that all occurrences of 
aBool arc shared so that all of them reduce either to True or to False consistently. 

The condition c in rule (1) typically is a conjunction of equational constraints of the form 
ei=: = e2. Such a constraint is satisfiable if both sides e\ and e-i are reducible to unifiable data 
terms. For instance, if the symbol "++" denotes the usual list concatenation operation, we can 
define an operation last that computes the last element e of a non-empty list xs as follows: 

last xs I ys++[e] = : = xs = e where ys , e free 

Like in Haskell, most rules defining functions are constructor-based [25], i.e., in (1) i 1; . . . ,t n consist 
of variables and/or data constructor symbols only. However, Curry also allows functional patterns 
[3], i.e., U might additionally contain calls to defined operations. For instance, we can also define 
the last element of a list by: 
last' (xs++[e]) = e 

Here, the functional pattern (xs++[e]) states that (last' t) is reducible to e provided that the 
argument t can be matched against some value of (xs++[e] ) where xs and e are free variables. By 
instantiating xs to arbitrary lists, the value of (xs++ [e] ) is any list having e as its last element. 
Functional patterns are a powerful feature to express arbitrary selections in term structures. For 
instance, they support a straightforward processing of XML data with incompletely specified or 
evolving formats [18]. 

3 The Compilation Scheme of KiCS2 

To understand the extensions described in the subsequent sections, we sketch the translation of 
Curry programs into Haskell programs as performed by KiCS2. More details about this translation 
scheme can be found in [10, 12]. 

As mentioned in the introduction, the KiCS2 implementation is based on the explicit repre- 
sentation of non-deterministic results in a data structure. This is achieved by extending each data 
type of the source program by constructors to represent a choice between two values and a failure, 
respectively. For instance, the data type for Boolean values defined in a Curry program by 

data Bool = False I True 
is translated into the Haskell data type 1 

data Bool = False I True I Choice ID Bool Bool I Fail 

The first argument of type ID of each Choice constructor is used to implement the call-time choice 
semantics discussed in Sect. 2. Since the evaluation of xorSelf aBool duplicates the argument 
operation aBool, we have to ensure that both duplicates, which later evaluate to a non-deterministic 
choice between two values, yield either True or False. This is obtained by assigning a unique 
identifier (of type ID) to each Choice. The difficulty is to get a unique identifier on demand, 
i.e., when some operation evaluates to a Choice. Since we want to compile into purely functional 
programs (in order to enable powerful program optimizations) , we cannot use unsafe features with 
side effects to generate such identifiers. Hence, we pass a (conceptually infinite) set of identifiers, 
also called identifier supply, to each operation so that a Choice can pick its unique identifier from 
this set. For this purpose, we assume a type IDSupply, representing an infinite set of identifiers, 
with operations 

initSupply : : 10 IDSupply 

thisID : : IDSupply — > ID 

lef tSupply : : IDSupply — > IDSupply 

rightSupply : : IDSupply — > IDSupply 

1 Actually, our compiler performs some renamings to avoid conflicts with predefined Haskell entities and 
introduces type classes to resolve overloaded symbols like Choice and Fail. 



The operation initSupply creates such a set (at the beginning of an execution), the operation 
thisID takes some identifier from this set, and leftSupply and rightSupply split this set into two 
disjoint subsets without the identifier obtained by thisID. There arc different implementations 
available [8] (see below for a simple implementation) and our system is parametric over concrete 
implementations of IDSupply. 

When translating Curry to Haskell, KiCS2 adds to each operation an additional argument of 
type IDSupply. For instance, the operation aBool defined in Sect. 2 is translated into: 

aBool : : IDSupply — ► Bool 

aBool s = Choice (thisID s) True False 

Similarly, the operation 

main : : Bool 

main = xorSelf aBool 

is translated into 

main : : IDSupply — > Bool 

main s = xorSelf (aBool (leftSupply s)) (rightSupply s) 

so that the set s is split into a set (leftSupply s) containing identifiers for the evaluation of aBool 
and a set (rightSupply s) containing identifiers for the evaluation of the operation xorSelf. 

Since all data types are extended by additional constructors, we must also extend the definition 
of operations performing pattern matching. 2 For instance, consider the definition of polymorphic 
lists 

data List a = Nil I Cons a (List a) 

and an operation to extract the first element of a non-empty list: 

head : : List a —5- a 
head (Cons x xs) = x 

The type definition is then extended as follows: 

data List a = Nil I Cons a (List a) I Choice ID (List a) (List a) I Fail 

The operation head is extended by an identifier supply and further matching rules: 

head : : List a — S> IDSupply — > a 

head (Cons x xs) s = x 

head (Choice i xl x2) s = Choice i (head xl s) (head x2 s) 

head _ s = Fail 

The second rule transforms a non-deterministic argument into a non-deterministic result and the 
final rule returns Fail in all other cases, i.e., if head is applied to the empty list as well as if the 
matching argument is already a failed computation (failure propagation). 

To show a concrete example, we use the following implementation of IDSupply based on un- 
bounded integers: 

type IDSupply = Integer 

initSupply = return 1 

thisID n = n 

leftSupply n = 2 * n 

rightSupply n = 2 * n + 1 

If we apply the same transformation to the rules defining xor and evaluate the main expression 
(main 1), we obtain the result 

Choice 2 (Choice 2 False True) (Choice 2 True False) 

Thus, the result is non-deterministic and contains three choices, whereby all of them have the same 
identifier. To extract all values from such a Choice structure, we have to traverse it and compute all 
possible choices but consider the choice identifiers to make consistent (left /right) decisions. Thus, 

2 To obtain a simple compilation scheme, KiCS2 transforms source programs into uniform programs 
[12] where pattern matching is restricted to a single argument. This is always possible by introducing 
auxiliary operations. 



if we select the left branch as the value of the outermost Choice, we also have to select the left 
branch in the selected argument (Choice 2 False True) so that False is the only value possible 
for this branch. Similarly, if we select the right branch as the value of the outermost Choice, we 
also have to select the right branch in its selected argument (Choice 2 True False), which again 
yields False as the only possible value. In consequence, the unintended value True is not produced. 

The requirement to make consistent decisions can be implemented by storing the decisions 
already made for some choices during the traversal. For this purpose, we introduce the type 
data Decision = NoDecision I ChooseLeft I ChooseRight 

where NoDecision represents the fact that the value of a choice has not been decided yet. Fur- 
thermore, we assume operations to lookup the current decision for a given identifier or change it 
(depending on the implementation of IDSupply, KiCS2 supports several implementations based on 
memory cells or finite maps): 

lookupDecision : : ID — » 10 Decision 
setDecision : : ID — ¥ Decision — ¥ 10 () 

Now we can print all values contained in a choice structure in a depth-first manner by the following 
I/O operation: 3 

print ValsDFS : : a -> 10 () 

print ValsDFS Fail = return () 

printValsDFS (Choice i xl x2) = lookupDecision i >>= follow 
where 

follow ChooseLeft = printValsDFS xl 
follow ChooseRight = printValsDFS x2 
follow NoDecision = do newDecision ChooseLeft xl 

newDecision ChooseRight x2 

newDecision d x = do setDecision i d 
printValsDFS x 
setDecision i NoDecision 

printValsDFS v = print v 

This operation ignores failures and prints values that are not rooted by a Choice constructor. For 
a Choice constructor, it checks whether a decision for this identifier has already been made (note 
that the initial value for all identifiers is NoDecision). If a decision has been made for this choice, 
it follows this decision. Otherwise, the left alternative is used and this decision is stored. After 
printing all values w.r.t. this decision, the decision is undone (like in backtracking) and the right 
alternative is used and stored. 

In general, this operation is applied to the normal form of the main expression (where 
initSupply is used to compute an initial identifier supply passed to this expression). The nor- 
mal form computation is necessary for structured data like lists, so that a failure or choice in some 
part of the data is moved to the root. 

Other search strategies, like breadth-first search, iterative deepening, or parallel search, can be 
obtained by different implementations of this main operation to print all values. Furthermore, one 
can also collect all values in a tree-like data structure so that the programmer can implement his 
own search strategies (this corresponds to encapsulating search [11]). Finally, instead of printing 
all values, one can easily define operations to print either the first solution only or one by one upon 
user request. Due to the lazy evaluation strategy of Haskell, such operations can also be applied 
to infinite choice structures. 

To avoid an unnecessary growth of the search space represented by Choice constructors, our 
compiler performs an optimization for deterministic operations. If an operation is defined by non- 
overlapping rules and does not call, neither directly nor indirectly through other operations, a 
function defined by overlapping rules, the evaluation of such an operation (like xor or not) can- 



3 Note that this code has been simplified for readability since the type system of Haskell does not allow 
this direct definition. 



not introduce non-deterministic values. Thus, it is not necessary to pass an identifier supply to 
the operation. In consequence, only the matching rules are extended by additional cases for han- 
dling Choice and Fail so that the generated code is nearly identical to a corresponding functional 
program. Actually, the benchmarks presented in [12] show that for deterministic operations this 
implementation outperforms all other Curry implementations, and, for non-deterministic opera- 
tions, outperforms Prolog-based implementations of Curry and can compete with MCC [24], a 
Curry implementation that compiles to C. 

As mentioned in the introduction, occurrences of logic variables are translated into generators. 
For instance, the expression "not x" , where x is a logic variable, is translated into "not (aBool s)" , 
where s is an IDSupply provided by the context of the expression. The latter expression is evaluated 
by reducing the argument aBool s to a choice between True or False followed by applying not to 
this choice. This is similar to a narrowing step on "not x" that instantiates the variable x to True 
or False. Since such generators are standard non-deterministic operations, they are translated like 
any other operation and, therefore, do not require any additional run-time support. However, in 
the presence of equational constraints, there are methods which are more efficient than generating 
all values. These methods and their implementation are discussed in the next section. 



4 Equational Constraints and Unification 

As known from logic programming, predicates or constraints are important to restrict the set of 
intended values in a non-deterministic computation. Apart from user-defined predicates, equational 
constraints of the form ei = : = e2 are the most important kind of constraints. We have already seen 
a typical application of an equational constraint in the operation last in Sect. 2. 

Due to the presence of non-terminating operations and infinite data structures, "=:=" is inter- 
preted as the strict equality on terms [15], i.e., the equation e\ = : = e2 is satisfied iff e\ and ei are 
reducible to unifiable constructor terms. In particular, expressions that do not have a value are 
not equal w.r.t. "=:=", e.g., the equational constraint "head [] =:= head []" is not satisfiable. 4 

Due to this constructive definition, "= : =" can be considered as a binary function defined by the 
following rules (we only present the rules for the Boolean and list types, where Success denotes 
the only constructor of the type Success of constraints): 



True 


=:= True 


= Success 




False 


=:= False 


= Success 




[] 


= := [] 


= Success 




(x : xs) 


=:= (y:ys) = 


= x =:= y J 


i xs = : = ys 


Success 


& c = c 







If we translate these operations into Haskell by the scheme presented in Sect. 3, the following rules 
are added to these rules in order to propagate choices and failures: 

Fail =:= = Fail 

Fail = Fail 

Choice i 1 r =:= y = Choice i (1 =:= y) (r =:= y) 

Choice i 1 r = Choice i (x =:= 1) (x =:= r) 
= Fail 

Fail & = Fail 

Choice i 1 r & c = Choice i (1 & c) (r & c) 

& = Fail 

Although this is a correct implementation of equational constraints, it might lead to an unneces- 
sarily large search space when it is applied to generators representing logic variables. For instance, 
consider the following generator for Boolean lists: 



4 From now on, we use the standard notation for lists, i.e., [] denotes the empty list and (x:xs) denotes 
a list with head element x and tail xs. 



aBoolList = [] ? (aBool : aBoolList) 

This is translated into Haskell as follows: 
aBoolList : : IDSupply — > [Bool] 

aBoolList s = Choice (thisID s) [] (aBool (leftSupply s) 

: aBoolList (right Supply s)) 

Now consider the equational constraint "x = := [True] " . If the logic variable x is replaced by 
aBoolList, the translated expression "aBoolList s =:= [True]" creates a search space when eval- 
uating its first argument, although there is no search required since there is only one binding for x 
satisfying the constraint. Furthermore and even worse, unifying two logic variables introduces an 
infinite search space. For instance, the expression "xs =:= ys & xs++ys =:= [True]" results in an 
infinite search space when the logic variables xs and ys are replaced by generators. 

To avoid these problems, we have to implement the idea of the well-known unification principle 
[28]. Instead of enumerating all values for logic variables occurring in an equational constraint, we 
bind the variables to another variable or term. Since we compile into a purely functional language, 
the binding cannot be performed by some side effect. Instead, we add binding constraints to the 
computed results to be processed by a search strategy that extracts values from choice structures. 

To implement unification, we have to distinguish free variables from "standard choices" (in- 
troduced by overlapping rules) in the target code. For this purpose, we refine the definition of the 
type ID as follows: 5 

data ID = ChoicelD Integer I FreelD Integer 

The new constructor FreelD identifies a choice corresponding to a free variable, e.g., the generator 
for Boolean variables is redefined as 

aBool s = Choice (FreelD (thisID s)) True False 

If an operation is applied to a free variable and requires its value, the free variable is transformed 
into a standard choice. For this purpose, we define a simple operation to perform this transforma- 
tion: 

narrow : : ID — )■ ID 

narrow (FreelD i) = ChoicelD i 

narrow x = x 

Furthermore, we use this operation in narrowing steps, i.e., in all rules operating on Choice con- 
structors. For instance, in the implementation of the operation not we replace the rule 

not (Choice i xl x2) s = Choice i (not xl s) (not x2 s) 
by the rule 

not (Choice i xl x2) s = Choice (narrow i) (not xl s) (not x2 s) 

As mentioned above, the consideration of free variables is relevant in equational constraints where 
binding constraints are generated. For this purpose, we introduce a type to represent a binding 
constraint as a pair of a choice identifier and a decision for this identifier: 

data Constraint = ID :=: Decision 

Furthermore, we extend each data type by the possibility to add constraints: 

data Bool = ... I Guard [Constraint] Bool 
data List a = ... I Guard [Constraint] (List a) 

A single Constraint provides the decision for one constructor. In order to support constraints 
for structured data, a list of Constraints provides the decision for the outermost constructor and 
the decisions for all its arguments. Thus, (Guard cs w) represents a constrained value, i.e., the 
value v is only valid if the constraints cs are consistent with the decisions previously made during 
search. These binding constraints are created by the equational constraint operation "=:=": if a 
free variable should be bound to a constructor, we make the same decisions as it would be done 

5 For the sake of simplicity, in the following, we consider the implementation of IDSupply to be unbounded 
integers. 



in the successful branch of the generator. In case of Boolean values, this can be implemented by 
the following additional rules for "= : =" : 

Choice (FreelD i) _ _ =:= True = Guard [i :=: ChooseLeft ] Success 
Choice (FreelD i) =:= False = Guard [i :=: ChooseRight] Success 

Hence, the binding of a variable to some known value is implemented as a binding constraint for 
the choice identifier for this variable. However, if we want to bind a variable to another variable, 
we cannot store a concrete decision. Instead, we store the information that the decisions for both 
variables, when they are made to extract values, must be identical. For this purpose, we extend 
the Decision type to cover this information: 

data Decision = . . . I BindTo ID 

Furthermore, we add the rule that an equational constraint between two variables yields a binding 
for these variables: 

Choice (FreelD i) _ _ =:= Choice (FreelD j) 
= Guard [i :=: BindTo j] Success 

The consistency of constraints is checked when values are extracted from a choice structure, e.g., 
by the operation printValsDFS. For this purpose, we extend the definition of the corresponding 
search operations by calling a constraint solver for the constraints. For instance, the definition of 
printValsDFS is extended by a rule handling constrained values: 

printValsDFS (Guard cs x) = do consistent <- add cs 

if consistent then do printValsDFS x 
remove cs 
else return () 

The operation add checks the consistency of the constraints cs with the decisions made so far and, in 
case of consistency, stores the decisions made by the constraints. In this case, the constrained value 
is evaluated before the constraints are removed to allow backtracking. Furthermore, the operations 
lookupDecision and setDecision are extended to deal with bindings between two variables, i.e., 
they follow variable chains in case of BindTo constructors. 

Finally, with the ability to distinguish free variables (choices with an identifier of the form 
(FreelD . . .) ) from other values during search, values containing logic variables can also be printed 
in a specific form rather than enumerating all values, similarly to logic programming systems. For 
instance, KiCS2 evaluates the application of head to an unknown list as follows: 

Prelude> head xs where xs free 
{xs = (_x2:_x3)} _x2 

Here, free variables are marked by the prefix _x. 
5 Functional Patterns 

A well-known disadvantage of equational constraints is the fact that "= : =" is interpreted as strict 
equality. Thus, if one uses equational constraints to express requirements on arguments, the result- 
ing operations might be too strict. For instance, the equational constraint in the condition defining 
last (see Sect. 2) requires that ys++[e] as well as xs must be reducible to unifiable terms so that 
in consequence the input list xs is completely evaluated. Hence, if failed denotes an operation 
whose evaluation fails, the evaluation of last [failed, True] has no result. On the other hand, the 
evaluation of last' [failed, True] yields the value True, i.e., the definition of last' is less strict 
thanks to the use of functional patterns. 

As another example for the advantage of the reduced strictness implied by functional patterns, 
consider an operation that returns the first duplicate clement in a list. Using equational constraints, 
we can define it as follows: 

fstDup xs I xs =:= ys++[e]++zs & elem e ys =:= True k nub ys =:= ys 
= e where ys , zs, e free 



The first equational constraint is used to split the input list xs into three sublists. The last 
equational constraint ensures that the first sublist ys does not contain duplicated elements (the 
library operation nub removes all duplicates from a list) and the second equational constraint 
ensures that the first element after ys occurs in ys. Although this implementation is concise, it 
cannot be applied to infinite lists due to the strict interpretation of "= : =" . This is not the case if 
we define this operation by a functional pattern: 

fstDup' (ys++ [e] ++zs) I elem e ys =:= True & nub ys =:= ys 
= e 

Because of the reduced strictness, the logic variable zs (matching the tail list after the first dupli- 
cate) is never evaluated. This is due to the fact that a functional pattern like (xs++ [e] ) abbreviates 
all values to which it can be evaluated (by narrowing) , like [e] , [xl , e] , [xl , x2 , e] etc. Conceptually, 
the rule defining last' abbreviates the following (infinite) set of rules: 



last ' [e] = e 




last' [xl,e] = e 




last' [xl,x2,e] = e 




Obviously, one cannot implement functional patterns by a transformation into 


an infinite set 


of rules. Instead, they are implemented by a specific lazy unification procedure 


"=:<=" [3]. For 


instance, the definition of last' is transformed into 




last' ys I (xs++[e]) = : <= ys = e where xs, e free 



The behavior of "= : <=" is similar to "= : =" , except for the case that a variable in the left argument 
should be bound to some expression: instead of evaluating the expression to some value and binding 
the variable to the value, the variable is bound to the unevaluated expression (see [3] for more 
details). Due to this slight change, failures or infinite structures in actual arguments do not cause 
problems in the matching of functional patterns. 

The general structure of the implementation of functional patterns in KiCS2 is quite similar 
to that of equational constraints, with the exception that variables could be also bound to uneval- 
uated expressions. Only if such variables are later accessed, the expressions they are bound to are 
evaluated. This can be achieved by adding a further alternative to the type of decisions: 
data Decision = ... I LazyBind [Constraint] 

The implementation of the lazy unification operation "= : <=" is almost identical to the strict unifi- 
cation operation "=:=" as shown in Sect. 4. The only difference is in the rules where a free variable 
occurs in the left argument. All these rules are replaced by the single rule 

Choice (FreelD i) __=:<= x 

= Guard [i :=: LazyBind (lazyBind i x)] Success 

where the auxiliary operation lazyBind implements the demand-driven evaluation of the right 
argument x: 

lazyBind : : ID — > a — > [Constraint] 
lazyBind i True = [i :=: ChooseLeft] 
lazyBind i False = [i :=: ChooseRight] 

The use of the additional LazyBind constructor allows the argument x to be stored in a binding 
constraint without evaluation (due to the lazy evaluation strategy of the target language Haskell). 
However, it is evaluated by lazyBind when its binding is required by another part of the computa- 
tion. Similarly to equational constraints, lazy bindings are processed by a solver when values are 
extracted. In particular, if a variable has more than one lazy binding constraint (which is possible 
if a functional pattern evaluates to a non-linear term), the corresponding expressions are evaluated 
and unified according to the semantics of functional patterns [3] . 

In order to demonstrate the operational behavior of our implementation, we sketch the evalua- 
tion of the lazy unification constraint xs++ [e] = :<= [failed, True] that occurs when the expression 
last' [failed, True] is evaluated (we omit failed branches and some other details; note that logic 
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last (map (inc 0) [1.. 10000]) 
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Fig. 1. Benchmarks: comparing different representations for equations 

variables are replaced by generators, i.e., we assume that xs is replaced by aBoolList 2 and e is 
replaced by aBool 3): 

aBoolList 2 ++ [aBool 3] = : <= [failed, True] 
~> [aBool 4, aBool 3] = : <= [failed, True] 

aBool 4 =:<= failed k aBool 3 =:<= True k [] =:<= [] 
~» Guard [4 :=: LazyBind (lazyBind 4 failed) 

, 3 :=: LazyBind (lazyBind 3 True)] Success 

If the value of the expression last ' [failed, True] is later required, the value of the variable e (with 
the identifier 3) is in turn required. Thus, (lazyBind 3 True) is evaluated to [3 : = : ChooseLeft] 
which corresponds to the value True of the generator (aBool 3). Note that the variable with 
identifier 4 does not occur anywhere else, so that the binding (lazyBind 4 failed) will never be 
evaluated, as intended. 

6 Benchmarks 

In this section we evaluate our implementation of equational constraints and functional patterns by 
some benchmarks. The benchmarks were executed on a Linux machine running Debian 5.0.7 with 
an Intel Core 2 Duo (3.0GHz) processor. KiCS2 has been used with the Glasgow Haskell Compiler 
(GHC 7.0.4, option -02) as its backend and an efficient IDSupply implementation that makes use 
of IORef s. For a comparison with other mature implementations of Curry, we considered PAKCS 
[19] (version 1.9.2, based on a SICStus-Prolog 4.1.2) and MCC [24] (version 0.9.10). The timings 
were performed with the time command measuring the execution time (in seconds) of a compiled 
executable for each benchmark as a mean of three runs. The programs used for the benchmarks, 
partially taken from [3], are last (compute the last element of a list), 6 simplify (simplify a 
symbolic arithmetic expression), varlnExp (non-deterministically return a variable occuring in a 
symbolic arithmetic expression), half (compute the half of a Peano number using logic variables), 
palindrome (check whether a list is a palindrome), horseman (solving an equation relating heads 
and feet of horses and men based on Peano numbers), and grep (string matching based on a 
non-deterministic specification of regular expressions [5] ) . 

In Sect. 4 we mentioned that equational constraints could also be solved by generators without 
variable bindings, but this technique might increase the search space due to the possibly super- 
fluous generation of all values. To show the beneficial effects of our implementation of equational 
constraints with variable bindings, in Fig. 1 we compare the results of using equational constraints 
(= : =) to the results where the Boolean equality operator (==) is used (which does not perform bind- 
ings but enumerate all values). As expected, in most cases the creation and traversal of a large 
search space introduced by == is much slower than our presented approach with variable bind- 
ings. In addition, the example last shows that the lazy unification operator ("=:<=") improves 
the performance when unifying an expression which has to be evaluted only partially. Using strict 
unification, all elements of the list are (unnecessarily) evaluated. 

In contrast to the Curry implementations PAKCS and MCC, our implementation of strict 
unification is based on an explicit representation of the search space instead of backtracking and 

6 "inc x n" is a naive addition that n times increases its argument x by 1. 
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Fig. 2. Benchmarks: strict unification in different Curry implementations 



Expression 


K1CS2 


PAKCS 


last (map (inc 0) [1.. 10000]) 


0.01 


0.33 


simplify 


7.07 


0.27 


varlnExp 


0.21 


1.87 


fromPeano (half (toPeano 10000)) 


11.19 


oo 


palindrome 


20.26 


oo 



Fig. 3. Benchmarks: functional patterns in different Curry implementations 



manipulating a global state containing bindings for logic variables. Nevertheless, the benchmarks 
in Fig. 2, using equational constraints only, show that it can compete with or even outperform 
the other implementations. The results show that the implementation of unification of MCC 
performs best. However, in most cases our implementation outperforms the Prolog-based PAKCS 
implementation, except for some examples. In particular, simplify does not perform well due to 
expensive bindings of free variables to large arithmetic expressions in unsuccessful branches of the 
search. Further investigation and optimization will hopefully lead to a better performance in such 
cases. 

As MCC does not support functional patterns, the performance of lazy unification is compared 
with PAKCS only (Fig. 3). Again, our compiler performs well against PAKCS and outperforms it 
in most cases ("oo" denotes a run time of more than 30 minutes). 



7 Conclusions and Related Work 

We have presented an implementation of equational constraints and functional patterns in KiCS2, 
a purely functional implementation of Curry. Our implementation is based on adding binding 
constraints to computed values and processing them when values are extracted at the top level of 
a computation. Since we only have added new constructors and pattern matching rules for them 
in our implementation, no overhead is introduced for programs without equational constraints, 
i.e., our implementation does not sacrifice the high efficiency of the kernel implementation shown 
in [12]. However, if these features are used, they usually lead to a comparably efficient execution, 
as demonstrated by our benchmarks. 

Other implementations of equational constraints in functional logic languages use side effects 
for their implementation. For instance, PAKCS [19] exploits the implementation of logic variables 
in Prolog, which are implemented on the primitive level by side effects. MCC [24] compiles into 
C where a specific abstract machine implements the handling of logic variables. We have shown 
that our implementation is competitive to those. In contrast to those systems, our implementation 
supports a variety of search strategies, like breadth-first or parallel search, where the avoidance of 
side effects is important. 

For future work it might be interesting to add further constraint structures to our implemen- 
tation, like real arithmetic or finite domain constraints. This might be possible by extending the 
kinds of constraints of our implementation and solving them by functional approaches like [29]. 
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